Conventionally, a user setting up an environment with multiple Internet-of-Things (IoT) devices, typically has to create and manage multiple user accounts, as the IoT devices are rarely made the from same manufacturer or operate with a same communication protocol. That is, different IoT devices/systems made by different manufacturers in general cannot form a single IoT system. The user needs to run multiple applications (apps), and set up accounts at multiple cloud servers, one for each IoT device or each IoT system made by a manufacturer. This is burdensome for the user and creates greater chances a user's password can be comprised, as a user often resorts to using a same username or password for multiple accounts.
A conventional IoT system can typically consist of a controlling unit and several devices made by the same manufacturer (such as a security camera system). A user downloads an app from the manufacturer for configuring and controlling the IoT system. The controlling unit and the devices typically have unique IDs and MAC addresses printed on the package or on the product. A user can find them over a wireless link and identify them based on such printed IDs and MAC addresses. There is no concept of proving the trustfulness of the IoT controlling unit and devices. Thus, a malicious device with the same look and printed label can trick the user into configuring and installing it, thus creating serious security concerns.
Currently, security studies on computer networking and communications system have not found a good solution to the problem of “trust of new device”, i.e., how to assure a new detected device that is to be configured and put into use is not a malicious device that looks identical to a legitimate device. A conventional approach can rely on a device having a secure boot feature to guarantee its software won't be altered, and the device possesses a secret that can authenticate itself as a proof of trust. However, there is no easy way to prove a device runs legitimate software that is guarded by secure boot feature, and a new device does not possess a secret shared with a user for authenticating purpose. A self-claimed secret or a self-claimed public key (such as those printed on the device package or user manual) do not prevent a malicious device from doing the same thing to trick the user. A security certificate issued by a well-known certificate authority (CA) or a server-verifiable public key can help create the trust, but they need careful management during device manufacturing, and thus add to the expense of the device.
This “trust of new device” problem can be even more challenging for IoT devices. First, IoT devices often lack, or have a very limited user interface, which prevent users from monitoring the software behavior of an IoT device. For example, a user can install anti-virus program on a computer to detect whether the computer runs spyware, but this cannot be done on an IoT device that runs closed, proprietary, embedded software. Second, IoT devices are typically large-volume devices, that are expected to have relatively low prices. Thus, individual security certificates built-in to each device during manufacturing can be prohibitively expensive. On the other hand, IoT devices typically do not work alone, and are typically configured into networks. Without a good solution to assure trust of new IoT device, a malicious IoT device could fool a user, get configured into a network, thus breaching the security of the entire network.
Currently, this “trust of new device” problem has not been sufficiently addressed by the IoT and related product markets.